Data organization is important in any database that deals with complex queries against large volumes of data. Disks or other storage devices on which the data is stored are generally divided into a set of “extents”. In a database system that includes a plurality of processing modules, individual processing modules have temporary control over one or more of the extents. Each extent is either temporarily owned by a processing module, or is free waiting to be allocated to a requesting processing module.
An allocation map controls the association of extents to processing module owners. The map is managed by a software process known as an allocator. When an extent is allocated, the allocator assigns a logical identifier to the extent and associates the logical identifier and the current owner with the extent by updating the allocation map. Usually an in memory copy of the map is kept and an on disk version of the map is only used for recovery. However, when an assignment or allocation occurs or an extent becomes free, the map entry must be written to disk before a confirmation is sent to the requesting processing module.
There can be problems where an interrupted write occurs. The allocator must ensure that the allocation map is valid even when problems such as interrupted writes caused by processing module or storage device failure occur.
Prior solutions to this interrupted write problem mostly involve keeping separate copies of the data. One solution is to write to alternating destinations. Another solution is to create a temporary duplicate copy of the data. In these cases the alternate data can be used to preserve an image of the data prior to the interrupted write problem. Such prior solutions generally require extra I/O operations to the allocation map and/or large amounts of space for duplicate entries.